In many scenarios, software delivered to a customer runs in an insecure environment for the software provider. Although some restriction mechanism is embedded inside the software package, such as “trial version” timing restrictions, customers still have strong motivation for cracking or bypassing the restriction functions to get more profits. Thus, protecting the restriction functions from being cracked or bypassed by malicious users in a hostile environment is always the concern.
With development of software services, many software providers provide service software or software modules. For software as a service offering deployed in insecure server in customer site, it's very hard to audit the transaction status of the service, though software providers always wish to do more micro-billing from their service operation.
A more general case is that those service components may be further integrated into new solutions deployed in some other customers' sites. In such cases, big concerns for the asset owner are how to be aware of the reuse status and how to control the usage to gain more profit.
In general, tamper-resistance technology (e.g., envelop) protects software programs from tampering or analyzing (e.g., extracting secret keys, proprietary algorithms, etc.). Most of the traditional tamper-resistance technologies are based on software approaches. These technologies encrypt the sensitive data/code of software to increase the bar that malicious users steal the secrets. However, the security level of pure software approaches is limited, facing the risk to be hacked by experienced crackers. Furthermore, it's hard to upgrade the security algorithm once a software program has been delivered to customer.
Another solution to avoid cracking is to migrate some key modules to the background server that is deployed at the software provider's site, that is, the secure domain. However, this solution will require the server deployed at a customer site to connect to the background server frequently, so it is not convenient for the customer (e.g., the customer may want to deploy the whole service product in a standalone laptop). Furthermore, in this case software providers have to maintain a 24/7 service to accept connections from customers.
The Trusted Platform (TP) is a computing platform with a trusted component, probably in the form of built-in hardware, which uses the component to create a foundation of trust for software processes. It uses trust based on integrity metrics of the platform to provide better security than pure software solutions. However, it's not always acceptable to deploy a TP module in customers' servers or machines. Besides, the memory size and CPU capability of certain trusted platforms may be limited to support the running service.
Dongles are used to keep software programs free from unauthorized copying, but they can't prevent the cracking or bypassing of the restriction functions.
Thus it can be seen that, in the prior art, either too low a software protection level is provided or a specific hardware is required, which are both undesirable for software providers. What is needed is a software protection technique capable of enhancing security of the software system running in the insecure environment to prevent tampering or bypassing without changing the existing hardware architecture.